For some time now, there has been a growing need to be able to inexpensively and easily connect a number of arbitrary devices to a computer running a standard operating system such as Microsoft Windows. However, connecting devices to a computer running such a complicated operating system presents at least two vexing problems to the system designer.
The first problem involves the matter of physical interconnection, that is, some type of custom device is to be plugged into the computer. General-purpose “IBM-compatible” computers have become more and more powerful and less and less expensive with every passing month, but that market is driven by a handful of more or less universal needs, such as a printer, a monitor, a keyboard, a mouse, a modem, and a hard disk. The modem hardware platform is optimized for accommodating these elements.
Meanwhile, the addition of custom equipment generally has meant either building an expansion board designed to specifically interface to that equipment, or buying a general-purpose board that could be adapted to that purpose. The least expensive of these options is to add an expansion board by building or buying an industry-standard architecture (ISA) board. However, as time goes on, modem central processing unit (CPU) boards are being built with fewer and fewer ISA slots. Many central processing unit boards these days have only one ISA slot. This forces designers to have to develop much more complicated and expensive Peripheral Component Interface (PCI) boards. A PCI bus provides a high-bandwidth data channel between system board components, such as the CPU, and devices, such as hard disks and video adapters. Another problem experienced today is that most central processing unit boards have a limited number of corn ports. This creates a limitation in the number of devices that can be utilized.
The second problem facing the system designer that wants to incorporate custom hardware into a Windows environment is the issue of software development. Operating systems, by definition, are in charge of resource management. To that end, operating systems regard any and all hardware attached to the system as belonging to the operating system. As a result, user access to that hardware is supposed to be mediated by the operating system.
Windows NT, for example, being a secure operating system environment, rigorously enforces that rule. Accordingly, the result of user access to hardware being mediated by the NT operating system is that any effort by an application to access hardware directly is intercepted and disabled by the operating system. Hence, access to hardware can only be achieved through device drivers, which are assumed to be trustworthy because they are loaded into the operating system at boot time.
Moreover, device driver programming is one of the most difficult software development paradigms in existence. Programming mistakes tend to make the computer crash, often without any indication of what went wrong. Debugging tools are primitive and difficult to use, and are limited in the information they convey. Each compile load-test cycle requires that the target machine be shut down and rebooted, which can take several minutes. Thus, the debugging process is often slow and discouraging work. In addition, many designers avoid performing Windows driver development. As a result, it is desirable to remove the need for developers to have to perform such work.
Another major problem experienced when connecting a number of arbitrary devices to a computer running a standard operating system, again, such as Microsoft Windows, is the issue of real time device control. Essentially, true real time depends upon the application. A standard Windows environment, such as Windows 98 or Windows 2000, does not actually have true real time device control requirements for resource management by the operating system. The operating system simply performs the ordered functions as soon as it is able, which is usually in a sub-200 millisecond time frame. This time frame is small enough that most people equate this response time to be “real time,” but in actuality it is not “true real time.”
However, many peripheral devices actually have true real time device control requirements that are more precise than the above-stated time interval. For example, loaves of bread may be traveling down a conveyer belt at a given number of miles per hour. These loaves of bread have to be sprayed by a butter sprayer at precise time intervals as the loaves of bread pass the sprayer. If these true real time device control requirements are not maintained, the butter sprayer will miss the loaves of bread as they pass by the sprayer. Unfortunately, previous attempts to make the standard Windows operating systems function with true real time device control (such as with layered real time systems or real time kernels), have proved to be undesirably expensive, complicated, and inflexible, requiring more corn ports to be added. Further, these ports are slow (typically 9600 baud) and do not address the need to mix high-speed data (video) and low speed data (mouse clicks) communications.
Accordingly, those skilled in the art have recognized the need for a device controller that has overcome the previous difficulties associated with physical interconnections between hardware, software, and operating systems; software development issues; and true real time device control. The system and method of the present invention is designed to eliminate the problems of hardware interconnection, software interfacing, and true real time device control. The present invention clearly fulfills these and other needs.